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Abstract 


This paper describes the design and verification strategies 
used to create a third generation symbolic processor op- 
timized for the Lisp language. The approach is unique in 
that it is probably the first large scale application of object 
oriented programming techniques to a production IC design 
problem. These techniques have yielded not only high 
productivity in the construction of the design tools but also 
clearly demonstrate the designer productivity available 


through the application of a well int 
design tools. well integrated set of VLSI 


1. Introduction 


Design and verification of complex architectures must occur 
at several widely separated levels of abstraction including 
the virtual machine, instruction set, architectural, gate and 
circuit levels. During the design, congruent descriptions 
must exist in the behavioral, schematic and layout domains. 
Many proposals have been made for dealing with the diverse 
levels of detail evident in these various design domains. Our 
common denominator is the Lisp language and the uniform 
virtual address space provided by the Lisp machine operat- 
ing system combined with an object-oriented electronic 
design system called NS. The result is no HDL but Lisp, 
no data files but Lisp data objects and no raw test vectors 
but Lisp code. We believe this approach is clean, easy to 
customize and extend, and requires little maintenance as 
Lisp is a commercially supported language with excellent 
compilers, editors, debuggers and advanced run-time en- 
vironments. 


NS [1] is a design system written in New Flavors, an object- 
oriented extension of Common-Lisp. Diagram objects and 
electrical network objects are the two basic object types 
upon which a wide variety of tools are based. A diagram ob- 
ject, for instance, might be a schematic which is comprised 
of lines, named terminals and hierarchical instances. x- 
traction is performed by traversing the diagram object. The 
result of extraction is an electrical network which consists 
of nodes, transistors and other primitive circuit elements. A 
switch-level simulator works by traversing the network ob- 
ject. Message passing between diagrams and networks yields 
an extensible design system with an effective user interface. 


The implementation of the Ivory single-chip Lisp 
microprocessor provided some interesting VLSI design trade- 
offs. It was undertaken by a small team of people, had to 
be completed in a short time and had to proceed in parallel 
with the refinement of the architecture. This paper sum- 
marizes the set of tools and design approaches used in the 
development of the chip. Where possible we will show how 
Lisp was used as a specification or verification language. 
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9 Architectural Design 


2.1 Architectural Simulation 


ct design level models. the I-machine (the 
eee porn sie galt the Ivory chip) by reflecting the 
state of the architecturally-defined stacks and registers. 
This level of design is used to verify the virtual machine 
architecture and gather architectural statistics. 


Two virtual machine simulators were written to model this 
level of the machine. The first was written by the VLSI 
group, while the second was written later in the design 
cycle by the software development group. Both use a fairly 
straightforward implementation of an instruction set 
emulator. This consists of a set of data structures modeling 
the relevant machine state (in this case, the system’s stacks 
and stack pointers) and a Lisp routine corresponding to 
each instruction which modifies the core data structures to 
reflect the effect of the instruction. The first simulator is 
2500 lines of Lisp and runs at 2000 instructions per second. 


The following represents the specification of the ADD in- 
struction at this level of design. 


(defemulator add operand 
(multiple-value-bind 
(first-operand second-operand) 
(fetch-two-operands operand) 
(stack-push (+ first-operand second-operand) ))) 


2.2 Behavioral Simulation 


The behavioral simulator was built using the object-oriented 
programming facilities provided by the Lisp Machine en- 
vironment. The system is decomposed into approximately 
20 modules, each of which is modeled as an instance of 
some class of objects. Each instance maintains private 
state. Attached to each class was a set of methods for im- 
plementing generic behavior in a manner suitable for ob- 
jects of that class. Each module defines a set of I/O signals 
that constitute a module’s communication ports. These 
specify the ports to be used in the circuit design. The fol- 


lowing specifies an adder with inputs opi and op2 and out- 
puts EXTERNAL-BUS. 


(defmodule (adder ivory) 
:local-state () 
: local-phase-1-registers () 
: local-phase-2-registers () 
:phase-1-registers () 
:phase-2-registers () 
:phase-1-inputs () 
:phase-1-outputs () 
:phase-2-inputs (op1 op2) 
:phase-2-outputs (external-bus) 
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Figure 1. Functional Simulator Window Interface 


An assembler supports the develo 
module. The following represents t 
for the ADD instruction: 


pment of the microcode 
he microcode specification 


(definstruction add 
(parallel 
(check-arithmetic-operands operand-1 operand-2) 
(pop2push (+ operand-1 operand-2)) 
(enabl e-overflow-exception) 
(next-instruction) )) 


The simulator and Lisp description of Ivory total 9000 lines 
of code including comments. The simulator runs at about 30 
instructions per second. 


What is novel about this simulator is its implementation 
technology and its relationship to its surrounding environ- 
ment. Since the simulator is part of a Lisp environment, it 
can write and execute other Lisp programs which execute 
within the same _ environment. Furthermore, these 
procedures can be individually modified and dynamically 
linked into the environment without interrupting normal ex- 
ecution. Therefore, there is no need to create a new HDL 
and implement the standard variety of control structures re- 
quired within it. Instead, the simulation routines are normal 
Lisp procedures with access to the full richness of the Lisp 
programming environment. 
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3. Structural Design 


The NS interactive editor provides for the capture of 
schematics and schematic-icons. A menu-driven generator 
tuulds mest common icons automatically. Figure 2 shows a 
yoew of the schematic editor with two views of a schematic. 
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Schematic Editor Interface 


—— 


A designer may enter schematics by the normal approach of 
graphical editing or may use a Lisp HDL to allow rapid and 
accurate entry of control logic. In the latter case, code can 
be for the most part taken directly from the behavioral 
simulator. The following description is representative: 


(def-std-cell-schematic ("simple-example” 
:inputs(p q a b) 
:outputs(z w)) 


(setq z (if (and p q) 
a 
b)) | 
(setq w (not (and ab) (or p q)))) 


When compiled, the logic is simplified and a rule-based 
technology selector optimizes the circuit used by choosing 
gates, merging gates and eliminating unnecessary inverters. 
A simple pattern matching language is used to apply the 
rules. The rules are augmented as different situations arise 


during the course of the design. The following represent 
rules for recognizing AOI’s. 


(def ine-eqn-transformer AOI 


(NOR (AND bcd 
(AND3-NOR2 a b c d)) ) a) 


(define-eqn-transformer AO] (NOR (NOR a b) 


(NOR c @)) 
(OR2-OR2-AND2 a b c d)) 


(def ine-eqn-transformer AO! (AND (NOT (NOR a b)) 


NOT (NO 
(OR2-OR2-AND2 abe d)) eS) 


These generally have a higher likeliho 
because they make the most efficie 
but equivalent logic expressions 
AOI. In all cases, the canonical 
the nested ANDs, ORs and NOTs 
gate (Le. an OR2-OR2-AND2) whi 
library. 


od of being accepted 
nt use of area. Different, 
can map onto the same 
expression represented by 
1S converted to a specific 
ch is in the standard cell 


Some rules implement demorganizing th 
clal a XORs), while le eps 
up rules (.e. it is advanta 

a latch). —s 


1s specific to Spe- 
recognize circuit speed- 
reduce the setup time to 


Finally, less desirable rules ar 
S € attempted which try to 
reduce the placement problem by assigning herp asl ie 


. s -cell, thu : 
ing occupancy. s reducing channel rout 


(def ine-eqn-transformer [IHPLOOE 


“pgs (NOT (NANO a b)) 


The designer can specify 


named gates (ie. . 
thereby forcing a specific gates (ie. NAND5, NORQ2) 


implementation. 


Although the designer does not have to b 
: e aware of the un- 
ee object-oriented data-base to complete designs “ 
: owledge of these details can aid productivity. Most of our 
esigners can write simple data-base query programs such 


as the following Lisp program which calcul 
| C : 
ternal capacitance of a network. culates the total in 


(defmethod (internal-capacitance rsim-network-mixin) () 
(loop for node in nodes 


unless (or (eq node gnd) 
(eq node vdd)) 
Sum (node-capacitance node))) 


A electrical rules checker is used to 


check port names, port 
directions, bus widths and ; : 


other structural rules. 
4. Physical Design 


All of the chip cell designs (including pads) are specified in 
the virtual grid symbolic layout style either with the NS 
graphics editor (color or monochrome) or via Lisp 
procedures. This is a process independent layout style in 
which the designer does not have to deal with geometric 
design rules. Rather transistors and wires are placed on a 
coarse grid in a relative manner to each other. Cell designs 
are compacted or spaced according to a target technology 
description. The design style can deal with large pitch- 
matched cells of the order of 50K transistors. Our ap- 
proaches to this are summarized in [2]. 


A standard cell layout system automatically generates sym- 
bolic layout from control schematic diagrams with the op- 
tion of using port locations specified by the mask-outline. 
Both min-cut and thermal-annealing [3] approaches have 
been used. Min-cut is much faster but thermal annealing 
has a slight density edge. We expect the min-cut density 
will improve and will become the automatic layout style of 
choice. The aspect ratio of the module may be specified to 
allow area tuning. Figure 3 shows a typical virtual grid 
standard cell layout with the contents of some cells dis- 


played. 


Data paths are constructed manually. Basic cells such as 
registers, muxes and adders are provided in a data-path 
standard cell library. To improve productivity, liberal use is 
made of generators [4]. The following generator horizontally 
abuts three cells and raises the instance ports to this level 


of the hierarchy. 


(defaspect-generator (data-path -Virtual-grid) (flag) 
(HORI ZONTALLY-ABUT ‘module-a 
(if flag 
‘'module-od 
‘module-d) 
‘module-c) 
(import-ports-on-edges) ) 
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Figure 3. A Symbolic Standard Cell Layout 


When all modules have been designed symbolically and com- 
pacted, the NS interactive editor is used to specify a slicing 
style floorplan [5][6]. Using the connectivity of the cor- 
responding schematic, this floorplan is used as the basis to 
automatically place and route the entire chip. A global 
router first assigns nets to the routing channels. When this 
is complete, modules are composed according to the floor- 
plan composition ordering. As they are connected, power, 
ground and clocks are also routed. This chip composition 
takes 2 hours to run for the complete Ivory chip. At early 
stages of design, partial floorplans can be constructed using 
estimates of block sizes. The following specifies the 
"example" module which has an estimated size of 250u by 
300u and has the inputs entering on the top and the out- 
puts exiting on the bottom. 


(def-mask-outline example (258 3@@) 
(:top "s<3:8>" 
memory-write-pending 
bus-master-pin) 
(:bottom mcw mcr mcrw)) 


Figure 4 shows the floor-plan of Ivory. 


A network comparison program is able to compare any two 
extracted networks (ie. from _ virtual-grid layouts, 
schematics, mask layouts and vendor net-list files)(7]. Inter- 
active feedback is provided to identify suspicious nodes. No 
node names are necessary. 


A fast interactive DRC is provided for final mask artwork 
checks. 
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Figure 4. A Floorplan View of Ivory 
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9. Simulation 


9.1 Circuit Simulation 


eg Simulator with timing (RSIM)[8] was used to 

pict calaa rae gate and switch level circuit simulation re- 

a -s Paes being optimized for fast simulation, 

dopa i 0 IM has the ability to specify functional 
els in the following manner (a RAM): 


(def functional-model cache- 
-inputs (“addre§- >" nr’ 
“Fow-enable 
write 
"Wri te-data<39:@>" 
‘Outputs (("“datac39:@>" aie 8/1 
: local-state ((cache-array 
hid ead 
| make-arra :initial- 
‘delays ((row-enablel -» Car at ea ran 
ible? > Anes 
(addr — -row-enable, :setup 16) 
as — —} writel ‘setup 15)) 
((eq) addr ‘x) 
(setq data ‘x)) 
((eql write 1) 
(setf (aref cache-array addr) 
write-data) 
(setq data write-data)) 
((eql write @) 
(setq data 
(aref cache-array addr))))) 


:pu-size 16/1)) 


Access to the RSIM simulator is available in parallel either 
via Lisp code that can set, read and compare values on a 
circuit node, or via mouse clicks on a schematic displayed in 
the graphics editor window. A hierarchical schematic can be 
traversed using PUSH/POP commands. The right window 
in Figure 2 displays the result of clicking near nodes. Test 
programs written in Lisp use a protocol consisting of three 
generic functions: 


® VALUE, which returns the value of a node, 
® SET-VALUE, which sets the value of a node, and 


® SIM-STEP, which propagates all changes through the net- 
work until no further changes occur. Optional ar- 
guments to SIM-STEP can specify the length of the 


simulation period. 


The normal Lisp-machine operating system features such as 
breakpointing, incremental compilation and function restart, 
along with the scope-probe capabilities of the NS design sys- 
tem, create an extremely powerful verification capability 
with a fast edit/compile/debug loop. This interactive circuit 
debugging capability is available on either schematics, sym- 
bolic layouts, or mask layouts. 


At the detailed circuit level, SPICE [9] was used to verify 
critical parts of the design, | such as adder speed and 
memory timing. An interactive interface is provided to 
SPICE which can be run locally on the Lisp machine or 
remotely over the network. Figure 5 shows a typical SPICE 
interaction session. 

To give some idea of the extensibility of NS, an experimen- 
tal timing simulator mode based on backward Euler integra- 
tion [10][11] was added to NS in a matter of a morning by a 
designer. We intend to incorporate parallel fault simulation 
‘nto RSIM in the future, but it will probably take more than 


a morning. 
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Figure 5. A SPICE window view of a module 


5.2 Hardware Simulation Acceleration 


Although RSIM is relatively fast (of the same order of speed 
as current software logic simulators), the size of some 
modules (and certainly the whole chip) results in simulation 
times beyond realistic limits. A number of methods are 
available to solve this problem, including operating one 
module at a time at the switch level while the others 
operate at the functional level. The solution we adopted 
was to invest in a hardware simulation accelerator. With a 
moderate software effort, we were able to create an inter- 
active environment for the engine that is identical to the in- 
teractive RSIM environment. The accelerator is currently 
the only method of simulating the entire chip at a suf- 
ficiently low level to give the chip designers confidence in 
the transistor-level design. The simulation speed is roughly 
10 instructions a minute. 


Apart from a UNIX" server and a Lisp-machine server re- 
quired to operate a network command protocol, the most 
significant piece of software is a "gate-recognizer.” To 
maximize modeling element use in the accelerator, all 
groups of transistors are converted to logic gates, unidirec- 
tional switches, or (if unavoidable) bidirectional switches. 


6. Design Verification 


6.1 Functional Comparison 


The consistency of the architectural and behavioral 
simulators is verified by applying a large set of test 
programs to each simulator and checking for consistency ac- 
cording to an instruction-set architecture specification. Com- 
paring the behavioral simulator and the circuit data-base 
can be performed on a signal by signal basis as the be- 
havioral simulator is used to specify the modularity and 
communication between modules of the chip. 


As both the behavioral simulator and RSI 
u ! M were 
mented using the object-oriented programming facilities of 


the Lisp machine, one can pass com 
mon message 
simulators to achieve the required behavior. oom 


imple- 


During verification, sET-VALUE mes 

the behavioral simulator and RSIM. Beaks ani — 
simulator takes the appropriate action to set as paler pe 
to a particular value. This is achieved using a "“forw rding 
network" which takes a list of two networks one the RSIM 


network and the other the beheviersl simulator ‘network’ 
amd the nede umder question and successively applies the 
Mi valu— procedure te both nodes in each simulator. Thus 
the seTv function ie used te set values in beth networks: 


\Gefeatnhad (sety forward'ng-cetuors) (node velue) 
(s@t-velus rs'e-neteorkt mode velue) 
(qet-veleue Gemevtore! -eode! rade vel ve) ) 


As the functional! simulator works with a two-phase clock, a 
function i written to emulate the cloces for the KSIM 
simulation. A simple version of this would look as follows 


(defwetned (siaulate-ofese-1 rsta-network-alxin) () 
(set-velue self ‘prt 1) 
(Sim-step self) 
(set-value self 
(Sim-steo self)) 


"prt @) 


This message is applied to both networks to advance 
through a phasel clock cycle. The following forwarding net- 
work function calls both phasel execution functions: 


(defmethod (pnasel forwarding network) () 
(si@ulate-phase-1 rsia-network) 
(simul ate-phase-1 behavioral-mode)) ) 


The VERIFY command operates by asking the two simulators 
for values and then comparing the results. If the results 
disagree, a debugging session with the user is initiated. 


The following represents a simple test program. 


(declare-bus ‘opi 32) 
(declare-bus ‘op2 32) 
(declare-bus ‘external-bus 32) 


(defun cospare-adder-ops (opi op2) 

(phase) 

(setv ‘opi opt ) 

(sety ‘op2 op2 ) 

(phase2) 

(verify ‘external -bus) ) 
Such programs are written by designers to test the 
functionality of individual modules. 


To provide higher level tests, a spy strategy was developed. 
With this facility, the complete behavioral simulator could 
be exercised by Lisp test programs. Arbitrary collections of 
modules can be grouped together (to model physical layout 
groupings) and their collective inputs and outputs monitored 
to provide a trace history of the boundary signals. The 
storage of the history allows both interactive and batch 
simulation. RSIM simulation code consisting of SETV and 
VERIFY statements, is generated from the history. This code 
was then applied directly to the extracted network with any 
discrepancies detected by VERIFY errors. 


The SPY code was extended to allow interfacing to an en- 
gineering tester. This allows interactive debugging of tests 
in an engineering environment that was closely linked to 
the program development environment of the Lisp machine. 


6.2 Timing Analysis 


im) alyzer based on finding critical paths through 
lier nd pone was implemented based on Crystal(12]. 
It was subsequently rewritten to incorporate ideas from 
Leadout [13]. The timing analyzer heuristically determines 
directions on bidirectional devices that cause loops in the 
circuit [14]. Support for functional models (using RSIM 


functional models) is also provided. 
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calculated incrementally. 


| . | “ROM and RAM) it takes 2 hours (on a 
Symbelice Sed Lisp machine) to find all clocking con 
straints 


7. Version Control 


involving , f people, 
it ny complex design involving a team oO ; 
mud ited be incorporated into « — he ati! hae 
inadvertent inclusion of erroneous esign aa ey ——— 
NS support for the update of stale data a ‘i hohe 
implemented a change control system calle g 
m stem. 
a tg design, specific verification steps os to og tem 
on each module. For instance, @ standard ce alae 
has to be electrical rule checked, port checked, ge od, 
auto-placed, compacted, net-compared and the mask a 
tion saved. For each different kind of module a particul 
"step" was written to describe the necessary construction 
and verification tasks. When the step was run, all files and 
their version numbers used in the execution of the step 
were recorded, A data-base was kept which could be queried 
for the steps that had been run and the steps that had to 
be run if any sub-module (and hence _archive file) was 
changed. The management system provides an up-to-date 
view of the design progress and can remotely execute jobs 
on vacant Lisp machines. Using a history of previous job 
times, it can predict the time to completion of a given 
tapeout run. 


To create and check the entire Ivory physical data-base 
takes 30 Lisp CPU days. By using machines in parallel over 
the network, this can be done in 3-4 days. While this might 
seem a long time, this is the time to create a totally new 
physical data-base. The incremental time to produce a new 
chip after a typical ECO is on the order of hours. 


8. Summary 


Currently, the NS design system is also being used in Sym- 
bolics for the board level design of products based on Ivory, 
gate array design and other internal product designs. 


The tools developed to design Ivory comprised approximately 
one third of the total design effort. Without such tools, it is 
unlikely that the design of a chip of the complexity of Ivory 
would have been successful at first silicon. Lisp is the 
design language and implementation language for the entire 
project. By designing in Lisp, no intermediate languages 
have to be designed and no extraneous parsers written. The 
full richness of the Lisp software development available to 
the Lisp system programmer is also available to the VLSI 
designer. 


All of the tools mentioned in this paper were written in 
New Flavors Lisp from scratch under the Symbolics Genera 
7 operating system by various of the authors of this paper. 
The NS system totals roughly 50K lines of code. The 
brevity of the code is derived from the object-oriented ap- 
proach which provides for modularity, reusability and exten- 
sibility. 

On the basis of the wide range of design activities sup- 
ported, the intimate integration of the tools, the small pro- 
gramming team size and the complexity of chip designed, 
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